[00:00.000 --> 00:09.460]  I'm an architect and a software engineer. I've designed and built the Nexus platform and the TAO framework.
[00:09.460 --> 00:15.840]  And so I'm here today to discuss with you about security-focused operating system design.
[00:15.840 --> 00:22.320]  A lot of this has kind of become born with the invention of the blockchain, right?
[00:22.320 --> 00:28.440]  Other methods of securing the operating system I've seen through methods of logical attestation
[00:28.440 --> 00:33.120]  that usually use a trusted platform module in order to create different security properties
[00:33.120 --> 00:35.080]  in the final system in the operating system.
[00:35.080 --> 00:41.660]  So this presentation I'm going to discuss exactly how some of these architectural components fit together.
[00:42.240 --> 00:48.480]  This operating system, LLLOS, is something that has begun development.
[00:48.480 --> 00:56.040]  So we're just in the final stages of architectural and we're now moving forward into the actual development cycles.
[00:56.040 --> 01:01.180]  So what is LLLOS? LLL stands for lower-level library.
[01:01.180 --> 01:05.560]  So this is a polymorphic template library. It's developed in C++.
[01:05.560 --> 01:11.280]  And it's the foundation of the TAO framework and all of the other components of Nexus.
[01:11.280 --> 01:16.280]  So it contains three main components, the LLC, the LLD, and the LLP.
[01:16.420 --> 01:20.760]  Otherwise known as lower-level cryptography, lower-level database, and lower-level protocol.
[01:20.760 --> 01:29.040]  So it's designed to be a standalone template database or template library that you can build different applications on.
[01:29.040 --> 01:32.180]  One of which is going to be this operating system.
[01:32.180 --> 01:37.920]  So the lower-level database is a constant-time database, order of one.
[01:37.920 --> 01:43.260]  So as far as our tests have gotten, we've gotten above a billion keys.
[01:43.260 --> 01:46.540]  And you have maybe about a 20% reduction in performance.
[01:46.540 --> 01:55.360]  So that's a very important component. As we start managing ever-growing datasets for blockchains, we need the database to actually not slow down.
[01:55.560 --> 02:00.300]  So we've been developing this database specifically over the past four years.
[02:00.300 --> 02:08.060]  And more recently have finally, with the combination of hash maps and bloom filters, primary and secondary bloom filters, and many other range proofs and things like that.
[02:08.060 --> 02:13.120]  We've been able to get it, like I said, up to a billion keys without actually losing any performance.
[02:13.120 --> 02:19.620]  The average read performance, random reads, is 180,000 records per second with no memory caching.
[02:19.720 --> 02:25.240]  The average write performance is 120,000 records per second with no buffering.
[02:25.240 --> 02:26.880]  That's just straight to the disk.
[02:26.880 --> 02:34.160]  And then the average number of keys that can be checked per second is about 630,000 without actually having to read the data.
[02:34.160 --> 02:36.280]  So this is just checking in the keychain.
[02:36.620 --> 02:40.380]  So the lower-level database is extremely fast, extremely efficient.
[02:40.380 --> 02:47.120]  And the beautiful thing is, as the dataset gets larger and larger and larger, you still retain that performance.
[02:47.120 --> 02:53.000]  So when you get close to a full dataset, it'll go down to about 150,000 random reads per second.
[02:53.000 --> 02:58.460]  And then the sequential reads end up being about 1.2 million records per second for sequential reads.
[02:58.460 --> 03:03.280]  So it's a very, very fast, low-level database that's designed for blanching applications.
[03:03.280 --> 03:09.140]  And it's part of the foundation of this operating system for managing different file clusters and things such as that.
[03:09.140 --> 03:14.940]  So the lower-level operating system is being designed for authentication up and down the OSI stack.
[03:14.940 --> 03:19.380]  For those that don't know what the OSI stands for, it stands for Open Systems Interconnection.
[03:19.380 --> 03:23.760]  And it is somewhat of a template stack that most of the Internet is built on.
[03:24.120 --> 03:27.840]  And it contains seven layers, which we'll get to on the next slide.
[03:28.240 --> 03:32.580]  The LLOS is being implemented for cube satellites and IoT devices first.
[03:32.580 --> 03:40.580]  So the consumer version of the operating system will be coming quite a bit later because there's a lot of extra user virtualization that needs to be done.
[03:40.580 --> 03:45.120]  But the core foundation of it is going to be running on IoT and cube satellites.
[03:45.300 --> 03:48.660]  And it virtualizes the user space through distributed computing.
[03:50.480 --> 03:52.260]  So what is Nexus?
[03:52.320 --> 03:56.020]  So Nexus is a seven-layer software stack as well as the OSI.
[03:56.020 --> 04:01.200]  And it's designed to interweave with the OSI stack, as you can see.
[04:01.200 --> 04:08.560]  You have the base layers, the physical layer, and then the data link, and then the network, transport, session, presentation, and application layer.
[04:08.560 --> 04:10.020]  And this is the OSI.
[04:10.120 --> 04:21.200]  So Nexus has seven layers as well, which is the network layer for the base layer, the ledger layer, then the register layer, the operation layer, the API layer, the logical layer, and the interface.
[04:21.600 --> 04:30.140]  So this Nexus software stack is designed to, as I said, interweave within the OSI and improve the security properties.
[04:30.140 --> 04:34.660]  As many of you know, the Internet was not developed with many security properties in mind.
[04:34.660 --> 04:49.440]  And operating systems, their design is a little bit archaic because we have new technology that can actually prevent a lot of the exploits that are available right now, such as ROP exploits and file system tampering and things such as that.
[04:49.660 --> 04:53.080]  So Nexus is a part of this LLOS.
[04:53.080 --> 04:55.440]  We'll be running in the kernel space, not the user space.
[04:55.440 --> 05:13.780]  And it's going to be using registers to authenticate and verify different pieces of this kernel, which is going to protect the kernel from having remote injection attempts, which I usually use the analogy most kernels are kind of like a big gooey lot.
[05:13.780 --> 05:16.880]  And you can inject anything into it, and the computer is just going to execute it.
[05:16.880 --> 05:24.560]  That's how ROP exploits work, is you just override a part of the executable memory, and then you're able to inject a virus right in through their open port.
[05:24.560 --> 05:28.420]  So this fortifies the kernel.
[05:28.420 --> 05:31.620]  What it does is it allows the kernel to know itself, right?
[05:31.620 --> 05:41.660]  Because when something doesn't know itself, it's very difficult for it to determine if there's an attack, because an attack is generally some sort of change in the normal conditions, normal operating conditions.
[05:41.660 --> 05:57.200]  So when we add Nexus into this kernel space, what we're able to do is we're able to start to discern, as a software operating system, what it is and what it isn't, so that you can detect new viruses coming into it.
[05:57.200 --> 06:04.940]  It's kind of like an immune system for your body, where the T cells are able to identify a virus because it knows itself and it knows something that's foreign.
[06:04.940 --> 06:12.380]  The same type of thing with the operating system is the operating system is going to know its base-level functionality, and it will be able to detect anything foreign that comes through.
[06:12.680 --> 06:17.300]  So a brief explanation of two of the layers of the Nexus software stack.
[06:17.300 --> 06:25.180]  The ledger layer, which is the second layer, it essentially manages ownership of the registers, and it's responsible for chaining data into immutable objects.
[06:25.180 --> 06:29.200]  It's verified through locking mechanisms that are validated through global consensus.
[06:29.560 --> 06:34.500]  Those are proof-of-stake, proof-of-work, and practical by default-tolerant algorithms.
[06:34.500 --> 06:38.020]  And it proves ownership and permissions of registers on the layer above.
[06:38.580 --> 06:48.920]  Now, the register layer, which is what we're going to be utilizing mostly in the development of this operating system, registers are little-state objects that hold data owned by the user that published it.
[06:48.920 --> 06:53.160]  And they can be transferred, written, or be used as proofs on the operations layer above.
[06:53.400 --> 06:58.640]  Now, object registers are a type-safe programmable object, allowing the creation of custom data types.
[06:58.640 --> 07:02.480]  And registers can point to one another, forming relational database models.
[07:02.480 --> 07:11.820]  So, when we're getting to the security-focused operating system design, LLOS has three main architectural components that will provide security to the kernel.
[07:11.900 --> 07:15.860]  The first one is runtime, memory, and binary verification.
[07:15.900 --> 07:18.880]  The second one is file integrity and Merkle trees.
[07:18.880 --> 07:21.580]  And then the third one is software-defined routers.
[07:21.580 --> 07:26.100]  And I'll get to each one of these points as we extrapolate it out further.
[07:26.500 --> 07:30.020]  So, runtime, memory, and binary verification.
[07:30.020 --> 07:32.140]  This is to protect against buffer overflows.
[07:32.140 --> 07:40.120]  Right now, the main ways that we can protect against buffer overflow attacks on the kernel space is to do randomized address creation.
[07:40.120 --> 07:46.060]  Or you do some form of allocation of only a certain aspect of the memory is actually executable.
[07:46.060 --> 07:51.680]  So that if you have an ROP exploit that does buffer overflow, it makes it very difficult.
[07:51.680 --> 07:52.420]  Yes.
[08:00.910 --> 08:02.810]  You're not seeing the changing slide?
[08:04.290 --> 08:05.630]  Is this better?
[08:05.630 --> 08:07.850]  Or are you still stuck on the first one?
[08:12.080 --> 08:13.600]  You can see it now?
[08:14.720 --> 08:15.680]  Okay.
[08:15.940 --> 08:22.020]  So, with the runtime, memory, and the binary verification, we're essentially able to start to isolate.
[08:22.020 --> 08:28.560]  We take some of the properties of protecting against buffer overflows, such as having a certain portion of the memory being executable.
[08:28.560 --> 08:36.240]  But what we do, especially if we're doing compiling environments, is you have to authenticate any executable code.
[08:36.240 --> 08:45.880]  So if there's any sort of memory that's loaded into the memory when I first execute the binary, that, when it is first loaded, is verified against a register entry as a checksum,
[08:45.880 --> 08:51.480]  which will ensure that you know the exact instruction set that is being executed by the CPU.
[08:51.480 --> 08:58.480]  And before anything is passed into the CPU, you are able to determine if it was tampered with.
[08:58.480 --> 09:04.660]  So we authenticate every aspect of the runtime environment, essentially requiring user action to change the kernel state.
[09:04.660 --> 09:09.860]  We use memory randomization, but more importantly, only small sections of the page memory will be executable.
[09:09.860 --> 09:18.300]  And as I was saying earlier, before we pass anything into the actual CPU, we want to run it through an authentication system,
[09:18.300 --> 09:26.120]  which is essentially verifying the checksum either on a blockchain register or a digital signature that is verified off of the crypto object register.
[09:26.120 --> 09:30.260]  And I will get to that in a little bit, how the architecture of Nexus works.
[09:30.480 --> 09:34.340]  But there's a special register that's created when you create a new signature chain.
[09:34.340 --> 09:39.520]  It contains a number of hashes that correlate to specific public keys.
[09:39.640 --> 09:45.120]  So this allows you to do offline verification of identity and verifying specific pieces of data
[09:45.120 --> 09:49.580]  without having to actually touch the blockchain or create a new blockchain entry.
[09:49.640 --> 09:54.500]  When you touch the blockchain, it would be generally mutating the state of a register.
[09:54.500 --> 09:58.320]  So if you're modifying a file, you would have to actually modify the blockchain state.
[09:58.320 --> 10:04.000]  But if you're just doing basic runtime environments, you have a user action required when you compile it
[10:04.000 --> 10:09.720]  that will sign that specific bytecode into a checksum to ensure that if any time during the runtime
[10:09.720 --> 10:13.380]  there is an exploit that happens to overwrite some of the executable memory,
[10:13.380 --> 10:21.480]  before that is actually executed from a function call, it will have to be verified through the blockchain register,
[10:21.480 --> 10:24.600]  which will protect any type of remote injection attack.
[10:24.600 --> 10:30.020]  So any part that is executed will require a user action to change executable memory.
[10:30.020 --> 10:35.180]  Like I was saying, a user action could be anything from updating the state of a register on the blockchain itself
[10:35.180 --> 10:40.900]  or using one of the crypto object register keys to sign any piece of data,
[10:40.900 --> 10:46.840]  which is another form of authentication that does not necessarily require the updating of a register state.
[10:46.840 --> 10:51.840]  So more persistent level data is going to be updated in registers and more temporary data
[10:51.840 --> 10:58.300]  such as a recently compiled binary will be just signed as a type of notarization,
[10:58.300 --> 11:03.980]  which will protect that specifically from being mutated if there's anything bad that happens during runtime.
[11:03.980 --> 11:09.740]  Runtime instructions must be authenticated with the register allocated on Nexus in order to be executed.
[11:09.740 --> 11:16.120]  So if I download a new application, the application developer will have a blockchain register
[11:16.120 --> 11:18.660]  associated with the binary that they created.
[11:18.720 --> 11:22.600]  So it's the same type of way of hashing your binary before you execute them.
[11:22.600 --> 11:27.360]  The kernel itself is going to be doing that on every level and verifying that off of a blockchain entry
[11:27.360 --> 11:33.540]  so that you won't have to necessarily manually go and verify the binary has not been tampered with.
[11:33.540 --> 11:36.700]  You're going to be able to do that at runtime and it's going to be fully automated
[11:36.700 --> 11:41.140]  so that any time that you're executing any bytecode on this operating system,
[11:41.140 --> 11:45.500]  it's going to be fully authenticated to ensure that nothing was tampered with during runtime.
[11:45.500 --> 11:50.880]  And these checks are going to be happening every so often to ensure that nothing has continued to be tampered with.
[11:50.880 --> 11:54.620]  Anything that goes to the CPU has to be verified before it runs.
[11:54.620 --> 11:59.480]  And that's a really important distinction that's going to protect this operating system architecture
[11:59.480 --> 12:02.780]  from exploits that are currently available on current computers.
[12:02.780 --> 12:06.680]  Because as I'm sure you guys know, user account control on Windows,
[12:06.680 --> 12:11.500]  to bypass it, you simply just inject your malware directly into explorer.exe
[12:11.500 --> 12:14.740]  and it executes that with elevated privileges
[12:14.740 --> 12:18.840]  because the operating system doesn't know what it was before the virus came in
[12:18.840 --> 12:22.340]  and it just executes and sends every instruction that's executable to the CPU
[12:22.340 --> 12:24.840]  without having any levels of discernment.
[12:24.840 --> 12:29.700]  And that's one thing that has created massive security flaws in so many different operating system designs.
[12:29.700 --> 12:35.380]  But this type of architecture has not been available until the creation of a blockchain.
[12:35.580 --> 12:42.560]  The other aspects or trusted assistation, which I've seen, which is another operating system design that I've studied,
[12:42.560 --> 12:48.240]  use the trusted platform module to create this type of this trust, I guess you can say,
[12:48.240 --> 12:50.460]  and authentication of different pieces of the data.
[12:50.780 --> 12:54.760]  But in this case, since we have a blockchain, we don't need to rely on all of those.
[12:54.760 --> 12:59.480]  And trusted platform module version 2.0 has been known to have backdoors to the NSA.
[12:59.480 --> 13:02.180]  So that's definitely not something that we want to utilize.
[13:02.220 --> 13:06.560]  So newly downloaded binaries will be authenticated from the developer's signature chain,
[13:06.560 --> 13:09.880]  requiring authentication before instructions are sent to the CPU.
[13:09.880 --> 13:12.120]  And that's another really important distinction.
[13:12.120 --> 13:15.660]  Because that means that nobody will be able to actually modify the binary.
[13:15.660 --> 13:21.340]  And before anything is ever executed, it's verified against the register that the developer of the software created.
[13:21.340 --> 13:25.460]  If you're compiling yourself, then you just do a simple digital signature on the end of the compilation
[13:25.460 --> 13:30.900]  that then locks and specifically hashes that into a temporary object
[13:30.900 --> 13:36.020]  that can then be used to determine if any of those instructions change during runtime,
[13:36.020 --> 13:40.780]  which would be a quick way to detect if there was a buffer overflow or ROP exploit
[13:40.780 --> 13:44.640]  that was used to try to inject a virus into the executable memory.
[13:46.020 --> 13:49.400]  So file integrity Merkle trees is the second aspect.
[13:49.400 --> 13:53.540]  So imagine the file system being authenticated using Merkle trees.
[13:53.540 --> 13:58.800]  But in a sense, you're going to have every block in the file actually contain a hash
[13:58.800 --> 14:01.200]  or be a leaf of that hash in the Merkle trees.
[14:01.200 --> 14:05.360]  So that you can independently verify the integrity of subsets of the file
[14:05.360 --> 14:07.040]  through having the Merkle path.
[14:07.180 --> 14:09.900]  And now when you create a new file in your file system,
[14:09.900 --> 14:12.920]  something that's outside of the scope of the kernel in the user space,
[14:12.920 --> 14:18.160]  that's going to require a user action, which is going to generate and compute this Merkle root.
[14:18.160 --> 14:22.540]  And this Merkle root will end up being a data member inside a special object register
[14:22.540 --> 14:26.220]  that is a pointer to the actual data itself.
[14:26.220 --> 14:31.440]  So the storage location of the data can be utilizing distributed file systems
[14:31.440 --> 14:33.740]  or your local file system or anything else like that
[14:33.740 --> 14:36.820]  with very high levels of security.
[14:36.820 --> 14:38.960]  Because we don't need to worry about file system tampering
[14:38.960 --> 14:45.580]  because it always requires this register from the blockchain to actually be verified.
[14:45.640 --> 14:51.240]  So this allows independent checking of file integrity on a per block level using Merkle paths.
[14:51.240 --> 14:54.060]  And one reason that we use a Merkle tree and Merkle paths,
[14:54.060 --> 14:57.120]  instead of hashing the entire file, we can only hash small subsets
[14:57.120 --> 15:00.040]  so that if you update an aspect of the file,
[15:00.040 --> 15:03.200]  you don't have to recompute every single hash for every single block.
[15:03.200 --> 15:08.040]  If you only modify one block, you only need to recalculate the Merkle path and the Merkle root
[15:08.040 --> 15:12.240]  rather than having to calculate every single leaf hash once again.
[15:12.640 --> 15:15.420]  So what this creates is an immutability quality to the file system
[15:15.420 --> 15:18.080]  and it prevents file system tampering.
[15:18.080 --> 15:22.020]  So viruses and malware won't be able to inject themselves into your file system
[15:22.020 --> 15:24.960]  because before you open any of the files, it'll check the integrity
[15:24.960 --> 15:28.640]  and you'll be able to detect very quickly if anything is tampered with.
[15:28.640 --> 15:31.420]  So the kernel itself will be doing this integrity checking
[15:31.420 --> 15:37.020]  and it will require specific user action in order to update on the blockchain.
[15:37.020 --> 15:41.900]  So this gives you a type of multi-layered security properties
[15:41.900 --> 15:45.260]  because in order to actually attack your physical computer now,
[15:45.260 --> 15:48.600]  you're going to actually have to attack the cryptography existing on the public network
[15:48.600 --> 15:52.260]  which increases the difficulty of the attack
[15:52.260 --> 15:55.900]  and reduces the attack surface down on the operating system level.
[15:56.700 --> 16:01.780]  So the next one is software-defined routers.
[16:01.780 --> 16:05.100]  So this is a really important component because Nexus in itself
[16:05.100 --> 16:08.220]  is eventually becoming a new internet protocol.
[16:08.220 --> 16:12.820]  As you see, we are a software stack similar to the OSI.
[16:12.880 --> 16:15.120]  And on our network layer, our physical layer,
[16:15.120 --> 16:18.460]  we're developing mesh network technology and satellite technology
[16:18.460 --> 16:22.520]  using ISM frequencies, which are publicly available frequencies,
[16:22.520 --> 16:28.360]  about 5.8 gigahertz band, in order to turn every single device into a node on the network.
[16:28.360 --> 16:30.660]  And this is where the software-defined routers comes in.
[16:30.660 --> 16:33.580]  As you guys know, dedicated router hardware is an old technology
[16:33.580 --> 16:37.880]  and it's proving to be ineffective. IPv6 is a very good example of it.
[16:37.880 --> 16:40.520]  We've been 20 years since that was actually developed
[16:40.520 --> 16:44.240]  and there's still not IPv6 routes across the internet.
[16:44.280 --> 16:48.180]  We also have other issues with BGP, which stands for Border Gate Protocol.
[16:48.180 --> 16:51.460]  Those routing tables can be manipulated and managing a large dynamic state
[16:51.460 --> 16:53.980]  will require a lot of inter-router communication.
[16:53.980 --> 16:56.480]  So when we're talking about a dynamic mesh network
[16:56.480 --> 16:59.580]  and a dynamic low-Earth orbit satellite constellation,
[16:59.580 --> 17:03.460]  conventional routing systems such as BGP just will not work.
[17:03.780 --> 17:07.020]  So this operating system in itself, inside the kernel space,
[17:07.020 --> 17:09.100]  will actually be running a software-defined router
[17:09.100 --> 17:13.040]  so that we can actually update it much quicker
[17:13.040 --> 17:15.920]  than you would be able to access the physical hardware.
[17:15.920 --> 17:18.860]  And what's interesting about it is we'll be able to actually
[17:20.160 --> 17:22.240]  create a stateless routing system
[17:22.240 --> 17:25.520]  that doesn't require a dynamic state to constantly update it
[17:25.520 --> 17:28.520]  and there will be no routing tables that can be manipulated.
[17:28.520 --> 17:31.540]  And then any time there's a type of mapping required,
[17:31.540 --> 17:35.500]  such as an ARP packet or any type of LISP mapping,
[17:35.500 --> 17:39.520]  which LISP stands for Locator Identifier Separation Protocol,
[17:39.520 --> 17:42.620]  which essentially is decoupling the identifier on the network layer
[17:42.620 --> 17:44.240]  from the actual routing locator.
[17:44.240 --> 17:48.000]  So in a conventional IP system, your IP address is
[17:48.000 --> 17:50.940]  both your locator, your physical location.
[17:50.940 --> 17:54.620]  Think of an IP address as a type of machine-readable address
[17:54.620 --> 17:58.080]  to a geographic location, so that when it hits the router
[17:58.080 --> 18:01.820]  and it hops, it knows, okay, I need to go in this specific direction
[18:01.820 --> 18:04.040]  so I'm going to take this route.
[18:04.280 --> 18:08.820]  And so we need authentication up and down the OSI stack.
[18:08.820 --> 18:10.920]  In a dynamic routing system, it can be stateless,
[18:10.920 --> 18:14.480]  increasing overall security and reducing the ability to spoof routing locators.
[18:14.480 --> 18:17.140]  So in LISP terminology, a routing locator
[18:17.140 --> 18:21.540]  is the actual physical location, and then the EID,
[18:21.540 --> 18:25.700]  stands for Endpoint Identifier, is your actual device-level identifier.
[18:25.700 --> 18:27.600]  So you will always be reachable.
[18:27.600 --> 18:31.280]  Think of it kind of like a phone number that doesn't change.
[18:31.280 --> 18:32.980]  When you roam between different cell phone networks,
[18:32.980 --> 18:36.120]  your phone number never changes. It's only your locator that changes.
[18:36.120 --> 18:38.840]  So your identifier, aka your phone number, won't ever change.
[18:38.840 --> 18:41.660]  So each device, including IoT and satellites,
[18:41.660 --> 18:44.600]  will have their own embedded system that uses
[18:44.600 --> 18:46.860]  the Locator Identifier Separation Protocol,
[18:46.860 --> 18:51.860]  which also allows us to connect with the old internet protocols as well.
[18:51.860 --> 18:54.680]  If you happen to have a gateway on that specific node
[18:54.680 --> 18:56.640]  to the old internet protocol,
[18:56.640 --> 19:00.600]  then that can add as another RLOC in the RLOC set,
[19:00.600 --> 19:04.580]  as well as you can have your software-defined routing system.
[19:04.580 --> 19:08.480]  So you'll be able to connect and connect with multiple networks at the same time,
[19:08.480 --> 19:11.680]  which is going to be very important as we're starting to expand out
[19:11.680 --> 19:15.680]  into a full, fully-blown new internet architecture.
[19:16.700 --> 19:20.940]  So a lot of this comes down with a stateless routing system.
[19:20.940 --> 19:23.440]  So in order to be effective as a new internet protocol,
[19:23.440 --> 19:27.360]  Nexus needs to handle dynamic routing systems for mesh networks and cube satellites.
[19:27.360 --> 19:29.980]  As I was touching on that, managing the state,
[19:29.980 --> 19:33.420]  especially when we have limited bandwidth from satellites and mesh,
[19:33.420 --> 19:35.760]  is not a viable solution.
[19:35.760 --> 19:38.280]  So BGP is not something that will work.
[19:38.280 --> 19:42.800]  So Nexus OS or LLOS contains, in the software-defined routing,
[19:42.920 --> 19:45.860]  a stateless routing system where all you will need to know
[19:45.860 --> 19:49.080]  is about the number of nodes that you are around,
[19:49.080 --> 19:50.900]  your nearest nodes, your nearest neighbors,
[19:50.900 --> 19:55.480]  because it can use a GPS-type routing system
[19:55.480 --> 19:58.660]  where you can actually use the natural positioning of things
[19:59.300 --> 20:02.620]  without needing a machine-readable address like an IP address
[20:02.620 --> 20:06.900]  to point and shoot and actually be able to get a fully effective route
[20:06.900 --> 20:09.240]  without each of the nodes having to know anything about each other.
[20:09.240 --> 20:11.600]  So this improves the overall network security
[20:11.600 --> 20:15.820]  because we're not relying on a constantly updating dynamic routing table.
[20:15.820 --> 20:18.600]  And if we wanted to add authentication into that routing table,
[20:18.600 --> 20:20.640]  if we were using, let's say, BGP,
[20:20.640 --> 20:22.820]  it's just going to increase the amount of computing cycles
[20:22.820 --> 20:24.340]  that we're going to need to utilize.
[20:24.340 --> 20:26.140]  And when we're dealing with cube satellites,
[20:26.140 --> 20:27.740]  computing cycles are extremely important
[20:27.740 --> 20:30.160]  because, if any of you are aware,
[20:30.160 --> 20:33.000]  in low-Earth orbit, you're still within the atmosphere,
[20:33.700 --> 20:37.220]  but you have a lot of radiation still.
[20:37.220 --> 20:40.800]  And so what happens is you get a high concentration of beta particles,
[20:40.800 --> 20:42.520]  which are essentially just stray electrons,
[20:42.520 --> 20:47.140]  that end up creating a high concentration in the gate of the transistor,
[20:47.140 --> 20:49.680]  which will flip the bit from a zero to a one
[20:49.680 --> 20:52.200]  because, generally, they're n-channel transistors.
[20:52.200 --> 20:56.720]  So when the bits flip, then you could ruin an entire data set
[20:56.720 --> 20:59.300]  if you don't have integrity checking on that.
[20:59.300 --> 21:02.260]  So you have to have multiple CPUs and multiple sticks of memory
[21:02.260 --> 21:06.200]  and a lot of checksumming on all of the internal state changes on the satellite
[21:06.200 --> 21:11.400]  in order to ensure that no radiation has come and tampered with that specific file.
[21:11.400 --> 21:13.740]  So when we're talking about...
[21:23.690 --> 21:28.890]  router, so that out-of-box, every device that runs this LLLOS
[21:28.890 --> 21:31.230]  will be able to connect to the routing system
[21:31.230 --> 21:33.630]  but also provide value to the routing system
[21:33.630 --> 21:36.330]  because the routing system will not work
[21:36.330 --> 21:41.010]  if there's not gamification in the underlying routing architecture.
[21:41.010 --> 21:43.910]  In other words, the internet right now only works
[21:43.910 --> 21:46.990]  because ISPs forward traffic for one another.
[21:46.990 --> 21:49.430]  And it's kind of an unwritten law.
[21:49.430 --> 21:51.550]  I'll forward for you if you forward for me.
[21:51.550 --> 21:53.970]  But that's generally only unicast traffic.
[21:54.230 --> 21:57.370]  Traffic does not generally get forwarded by ISPs
[21:57.370 --> 21:59.610]  because there's no incentive for them to have that.
[21:59.610 --> 22:03.010]  So the entire internet game theory is slightly...
[22:03.890 --> 22:05.950]  is not properly thought out
[22:05.950 --> 22:08.390]  because the internet, kind of like Bitcoin, was an experiment
[22:08.390 --> 22:12.290]  that grew very quickly and became something predominant in the world
[22:12.290 --> 22:15.170]  and they constantly are spending time trying to catch up
[22:15.170 --> 22:18.730]  and resolve the problem that just became from the success,
[22:18.730 --> 22:20.010]  the initial success.
[22:20.010 --> 22:23.830]  So this routing system needs to have a type of reputation system
[22:23.830 --> 22:25.210]  built into the protocol
[22:25.210 --> 22:28.990]  so that nodes that route for one another
[22:28.990 --> 22:32.330]  end up becoming higher or having a higher reputation
[22:32.330 --> 22:34.930]  and nodes that do not route for one another
[22:34.930 --> 22:36.170]  end up getting a lower reputation
[22:36.170 --> 22:38.530]  which gives them a lower probability of their packets
[22:38.530 --> 22:40.490]  getting forwarded through the routing system.
[22:40.490 --> 22:41.890]  And that's a really important component
[22:41.890 --> 22:44.110]  because that will discern the difference
[22:44.110 --> 22:46.810]  between an honest node and a dishonest node.
[22:46.810 --> 22:49.590]  If somebody comes in just being a leech into the system,
[22:49.590 --> 22:52.030]  they're eventually going to leech themselves into isolation
[22:52.030 --> 22:56.310]  because if they refuse to forward packets for their neighbors,
[22:56.310 --> 22:58.430]  their reputation is going to slowly be reduced
[22:58.430 --> 23:01.390]  to the point where their neighbors will stop forwarding packets for them
[23:01.390 --> 23:04.070]  so they will be disconnected from the mesh network
[23:04.070 --> 23:06.910]  with a lower reputation and unable to route
[23:06.910 --> 23:10.230]  essentially degrading them into just a single device network
[23:10.230 --> 23:12.630]  rather than being able to join the entire network.
[23:12.630 --> 23:15.210]  So this reputation is a really important component
[23:15.210 --> 23:17.190]  inside the stateless routing system.
[23:17.190 --> 23:19.710]  And this is why the locator identifier separation protocol
[23:19.710 --> 23:21.530]  is really important because whether or not
[23:21.530 --> 23:24.770]  I'm routing on the regular IP internet protocol
[23:24.770 --> 23:27.510]  or I'm routing on the Nexus protocol,
[23:27.510 --> 23:29.110]  it's going to be...
[23:29.110 --> 23:32.430]  it's still going to need to have this reputation built into it
[23:32.430 --> 23:37.230]  so that nodes know more about who one another is
[23:37.230 --> 23:39.090]  and they'll all need to have this identifier
[23:39.090 --> 23:41.650]  which is cryptographically enforced.
[23:41.750 --> 23:44.750]  So as I was stating earlier with this crypto object register
[23:44.750 --> 23:49.550]  which contains nine 256-bit hashes of public keys,
[23:49.550 --> 23:52.450]  there's one specific key called the Lisp key.
[23:52.450 --> 23:55.810]  So when I create a new RLOC mapping into the mapping system,
[23:55.810 --> 23:58.430]  I'm essentially going to be registering this RLOC
[23:58.430 --> 24:01.830]  which could be an IP address or it could be an NP address
[24:01.830 --> 24:03.130]  or a Nexus protocol address
[24:03.690 --> 24:05.710]  for the stateless routing system.
[24:07.110 --> 24:10.750]  So it needs to be able...
[24:10.750 --> 24:14.310]  so in order to register this, I need to make a digital signature
[24:14.310 --> 24:17.310]  and sign this RLOC in with my EID
[24:17.310 --> 24:20.350]  and this mapping needs to be stored in state in the network
[24:20.350 --> 24:24.290]  so that they can know specifically where to send packets to me.
[24:24.290 --> 24:26.890]  So the locator identifier separation protocol
[24:26.890 --> 24:29.850]  is a really important component to the stateless routing system.
[24:29.850 --> 24:33.810]  And what it does is it opens us up to create network-level identifiers
[24:33.810 --> 24:36.810]  along with cryptographic identifiers.
[24:36.910 --> 24:40.150]  And this routing system also contains some elements of the OSI
[24:40.150 --> 24:43.190]  such as ARP, but rather authenticating each device
[24:43.190 --> 24:45.070]  with their own embedded subchain.
[24:45.350 --> 24:50.190]  So ARP caches will not be able to be corrupted or poisoned
[24:50.190 --> 24:53.170]  in this sense because it will be authenticated.
[24:53.170 --> 24:55.610]  Like I said, everything up and down the OSI stack
[24:55.610 --> 24:59.070]  needs to be authenticated to provide the security qualities that are required.
[25:01.150 --> 25:04.070]  So authenticate, authenticate, authenticate.
[25:04.070 --> 25:07.410]  As I was saying, every aspect of the stack and the operating system
[25:07.410 --> 25:11.150]  needs to authenticate a user's action through an immutable source of truth
[25:11.150 --> 25:12.490]  which is Nexus.
[25:12.530 --> 25:15.370]  And any changes to the state of the virtualized user space
[25:15.370 --> 25:17.610]  must be accompanied by a digital signature
[25:17.610 --> 25:19.930]  linked to the crypto-object register of the SIG chain
[25:19.930 --> 25:22.730]  or an op-write operation to the register
[25:22.730 --> 25:25.470]  that owns that specific part of the user space.
[25:25.470 --> 25:28.030]  So this means if I update and save a file
[25:28.030 --> 25:31.890]  this file actually needs to have the blockchain entry updated as well
[25:31.890 --> 25:34.550]  so that you can constantly have a history of changes
[25:34.550 --> 25:38.390]  and you'll also have a checksum, both ciphertext and plaintext
[25:38.390 --> 25:42.450]  in order to ensure that the file is not tampered in any way.
[25:42.450 --> 25:45.630]  Because when you allow the file system to have injection happen
[25:45.630 --> 25:49.070]  and executable memory to be run
[25:49.070 --> 25:53.690]  then you essentially create a lot of export opportunities for different hackers.
[25:53.810 --> 25:56.690]  So everything needs to be authenticated.
[25:56.690 --> 25:59.750]  And now that we have this technology with Nexus and blockchain
[25:59.750 --> 26:02.950]  we can provide these types of authentications.
[26:03.150 --> 26:06.670]  Beforehand, there always was a need for some centralized counterpart
[26:06.670 --> 26:09.190]  and that's how the Internet's architecture is designed right now.
[26:09.190 --> 26:11.570]  It only operates because there's trust.
[26:11.870 --> 26:14.410]  And that model works to a certain degree
[26:14.410 --> 26:17.010]  but it doesn't scale out very far
[26:17.010 --> 26:21.910]  and it also has corruption issues as we've seen with ICANN and Verisign.
[26:21.970 --> 26:24.310]  ICANN got a really large donation from Verisign
[26:24.310 --> 26:28.250]  and now Verisign can increase the cost of .com domains ad infinitum.
[26:28.250 --> 26:31.190]  So those types of issues won't really exist on Nexus
[26:31.870 --> 26:33.870]  because everything's going to be authenticated.
[26:33.870 --> 26:36.290]  You're not going to be able to just masquerade
[26:36.290 --> 26:39.470]  and you're not going to be able to pollute a centralized authority
[26:39.470 --> 26:43.650]  because Nexus becomes that incontrovertible port of truth.
[26:43.690 --> 26:46.370]  Now, going to the crypto object register again
[26:46.370 --> 26:50.270]  there's another specific hash in there which is for a certificate.
[26:50.490 --> 26:52.190]  So this is another really important distinction
[26:52.190 --> 26:56.310]  because we can actually, in the Diffie-Hellman key exchange
[26:56.310 --> 26:59.070]  we can actually hash that certificate that they give us
[26:59.070 --> 27:02.370]  and do a blockchain lookup to their blockchain identifier
[27:02.970 --> 27:05.110]  which we call a Genesis ID.
[27:05.230 --> 27:09.310]  And you can therefore verify with incontrovertible truth
[27:09.310 --> 27:14.370]  that that certificate was generated by the other end user.
[27:14.370 --> 27:16.210]  So you don't have man in the middle attacks
[27:16.210 --> 27:18.110]  and you don't need to have a public key database
[27:18.110 --> 27:21.350]  which is essentially what a certificate authority is.
[27:21.350 --> 27:25.350]  So executable instructions must be verified to a blockchain register
[27:25.350 --> 27:29.150]  or digitally signed binary compiled before passing to the CPU
[27:29.150 --> 27:31.450]  to protect against buffer overflow exploits
[27:31.450 --> 27:33.450]  or malware injection into the local files.
[27:33.450 --> 27:35.450]  So as I was stating earlier,
[27:35.450 --> 27:38.530]  executable memory is going to be treated very, very carefully
[27:38.530 --> 27:40.130]  on the kernel level.
[27:40.130 --> 27:43.370]  And it will be very, very difficult for you to inject
[27:43.370 --> 27:47.530]  any instructions that were not created on a user's action.
[27:47.530 --> 27:51.490]  So you will still have security properties
[27:51.490 --> 27:53.830]  or security issues and exploits
[27:53.830 --> 27:56.430]  with social engineering attacks and all of those things.
[27:56.430 --> 27:57.790]  But what we're doing here is
[27:58.390 --> 28:01.150]  we're essentially reducing the ability for developers
[28:01.150 --> 28:04.810]  to make mistakes that open up significant security holes.
[28:04.810 --> 28:06.690]  And the operating system protects against that
[28:06.690 --> 28:09.310]  on many different layers through this authentication.
[28:11.270 --> 28:14.810]  So device level identification is another really important distinction
[28:14.810 --> 28:17.050]  and this ties in with the IoT devices
[28:17.050 --> 28:20.670]  because we need an unforgeable device level authentication
[28:20.670 --> 28:23.330]  that allows easy identification of the device,
[28:23.590 --> 28:24.990]  especially for IoT.
[28:25.210 --> 28:26.830]  So what we're doing is
[28:26.830 --> 28:29.210]  we're taking a device level identification
[28:29.910 --> 28:33.550]  from deterministic hardware inputs such as IMEI
[28:33.550 --> 28:35.090]  or anything that you can utilize
[28:35.090 --> 28:38.110]  to generate a cryptographic identity
[28:38.110 --> 28:39.670]  which is called the signature chain.
[28:39.670 --> 28:42.390]  And that's essentially how we manage accounts on Nexus.
[28:42.390 --> 28:45.210]  A signature chain is kind of like a personal blockchain.
[28:45.210 --> 28:46.210]  We give it as a mini blockchain
[28:46.210 --> 28:48.950]  that is a local state or a local scope
[28:48.950 --> 28:50.590]  to that specific user.
[28:51.190 --> 28:52.910]  So when we tie this in
[28:52.910 --> 28:55.070]  with the locator identifier separation protocol,
[28:55.070 --> 28:56.970]  you get this unique identifier
[28:56.970 --> 28:58.770]  as a cryptographic identifier
[28:58.770 --> 29:01.390]  that you can use as a lookup into the global state
[29:01.390 --> 29:03.810]  and the blockchain, essentially.
[29:03.810 --> 29:06.010]  Or you can use it as a network level identifier
[29:06.010 --> 29:07.790]  that will allow you to do a lookup
[29:07.790 --> 29:10.130]  on the specific person that you are communicating with
[29:10.130 --> 29:11.990]  and decide whether or not
[29:11.990 --> 29:14.170]  you want to accept anything from them.
[29:14.170 --> 29:16.210]  And this also allows you to authenticate and verify
[29:16.210 --> 29:18.130]  files that are sent to you.
[29:18.150 --> 29:20.650]  So this gives each device a network identity
[29:20.650 --> 29:22.110]  that exists in the kernel space
[29:22.110 --> 29:24.490]  and is therefore immutable and tied deterministically
[29:24.490 --> 29:26.770]  to the device level hardware identifiers.
[29:27.030 --> 29:30.370]  So this is really important for...
[29:30.370 --> 29:33.650]  an example would be a smart lock IoT device.
[29:34.010 --> 29:36.730]  So this device itself would be running LLOS
[29:36.730 --> 29:39.290]  and it would have a device level signature chain
[29:39.290 --> 29:42.110]  so it has a cryptographic identity on Nexus
[29:42.110 --> 29:44.870]  that can be verified by any individual.
[29:45.110 --> 29:47.690]  And when you first start the device
[29:47.690 --> 29:49.810]  it's going to require some sort of binding
[29:49.810 --> 29:51.670]  where you're going to bind the device
[29:51.670 --> 29:53.590]  to another identifier.
[29:53.710 --> 29:56.890]  This identifier is the actual user level signature chain.
[29:56.890 --> 29:58.630]  The device level signature chain
[29:58.630 --> 30:00.370]  is a device level signature chain.
[30:00.370 --> 30:03.110]  It doesn't necessarily have all of the full range
[30:03.650 --> 30:06.810]  of operations available as a user signature chain.
[30:06.810 --> 30:09.850]  And obviously you can't apply a device signature chain
[30:09.850 --> 30:11.070]  to own a device signature chain.
[30:11.070 --> 30:13.130]  So this user signature chain becomes
[30:13.130 --> 30:15.010]  therefore the control of the device.
[30:15.010 --> 30:16.670]  Now, the device level signature chain
[30:16.670 --> 30:20.170]  is just for authenticating things specific to that device.
[30:20.170 --> 30:21.690]  The user level signature chain
[30:21.690 --> 30:23.630]  will exist outside of that device
[30:23.630 --> 30:26.390]  which essentially reduces the capacity
[30:26.390 --> 30:28.790]  for you to be able to hack IoT devices
[30:28.790 --> 30:31.150]  because the device itself will have
[30:31.150 --> 30:33.370]  nothing of value to hack.
[30:33.710 --> 30:35.990]  There's nothing stored on that device
[30:35.990 --> 30:38.790]  that will be of use to hack.
[30:38.790 --> 30:40.410]  Because that device level signature chain
[30:40.410 --> 30:43.390]  is going to obey this public signature chain,
[30:43.390 --> 30:44.750]  this user level signature chain.
[30:44.750 --> 30:46.730]  And it requires that user signature chain
[30:46.730 --> 30:48.030]  in order to have action.
[30:48.030 --> 30:50.890]  So the attack surface gets greatly reduced
[30:50.890 --> 30:52.810]  from the actual hardware in the device itself
[30:52.810 --> 30:55.990]  and it becomes more of a cryptographic attack
[30:55.990 --> 30:56.970]  on the actual blockchain
[30:56.970 --> 30:59.350]  in order to overtake some of these devices
[30:59.350 --> 31:00.850]  and access them.
[31:00.910 --> 31:03.650]  So this gives each device
[31:03.870 --> 31:05.990]  a network identity, as I was saying.
[31:05.990 --> 31:07.590]  And with it being deterministic
[31:07.590 --> 31:08.990]  to the device level hardware
[31:08.990 --> 31:11.650]  that means we'll have unique identifiers
[31:11.650 --> 31:13.090]  for each one of these devices.
[31:13.090 --> 31:14.910]  Now, each one of these devices will then also
[31:14.910 --> 31:17.490]  have their own unique IP address
[31:17.490 --> 31:18.750]  or crypto EID
[31:18.750 --> 31:20.290]  which will be the identifier
[31:20.740 --> 31:22.370]  so that we'll start to be able to identify
[31:22.370 --> 31:24.130]  each device individually.
[31:24.130 --> 31:27.270]  So in the example of SmartLock
[31:27.270 --> 31:28.990]  you get the device
[31:28.990 --> 31:30.890]  you set up the device
[31:30.890 --> 31:32.370]  by creating the owner
[31:32.370 --> 31:34.390]  the owner of the device would be
[31:34.390 --> 31:36.830]  the user level signature chain, public signature chain
[31:36.830 --> 31:38.550]  which can be done via
[31:38.870 --> 31:40.210]  a register that's created
[31:40.590 --> 31:42.530]  on the device. Now,
[31:42.530 --> 31:44.210]  if I have another specific user
[31:44.730 --> 31:46.490]  somebody that is coming to my house
[31:46.490 --> 31:47.810]  let's say at 5 o'clock PM
[31:47.810 --> 31:50.810]  I can set on the device
[31:50.810 --> 31:52.670]  itself or the user level signature chain
[31:52.670 --> 31:54.810]  I create a type of contract
[31:54.810 --> 31:56.510]  that says this device
[31:56.510 --> 31:58.650]  allows this specific
[31:58.650 --> 32:00.490]  identifier to open my door
[32:00.490 --> 32:02.470]  one time at this specific
[32:02.470 --> 32:04.190]  time stamp in the future.
[32:04.190 --> 32:05.790]  So that that user
[32:05.790 --> 32:07.910]  having another user level signature chain
[32:07.910 --> 32:09.690]  will go to the actual lock
[32:09.690 --> 32:11.390]  and through near field communication
[32:11.390 --> 32:13.410]  will send a digital signature
[32:14.190 --> 32:14.490]  signed
[32:16.230 --> 32:17.750]  from one of the
[32:17.750 --> 32:20.110]  hashed public keys in their crypto object register
[32:20.110 --> 32:22.170]  which is tied to that identifier
[32:22.170 --> 32:24.190]  that cryptographic identifier so the device
[32:24.190 --> 32:26.270]  can authenticate this person is this person
[32:26.270 --> 32:28.370]  cryptographically and then the door can open.
[32:28.370 --> 32:29.890]  So you create this very
[32:29.890 --> 32:31.990]  interesting type of usage of IoT
[32:31.990 --> 32:33.650]  devices and also a consistent
[32:33.650 --> 32:35.970]  standardization between different devices
[32:35.970 --> 32:37.550]  as I'm sure all of you are aware
[32:37.550 --> 32:39.650]  IoT devices have no standards
[32:39.650 --> 32:41.910]  they have very weak security
[32:41.910 --> 32:43.450]  there's not, there's
[32:43.870 --> 32:45.690]  a lot of explosion
[32:45.690 --> 32:47.870]  in the development of them but not
[32:47.870 --> 32:50.030]  as much understanding
[32:50.030 --> 32:51.510]  of the security properties kind of like
[32:51.510 --> 32:53.830]  the internet was or still
[32:53.830 --> 32:55.510]  is. So
[32:55.510 --> 32:57.890]  this operating system is
[32:57.890 --> 33:00.210]  also a means to standardize
[33:00.210 --> 33:02.050]  the communication protocols between all
[33:02.050 --> 33:04.210]  these devices and improve the overall
[33:04.210 --> 33:05.690]  IoT security.
[33:06.170 --> 33:08.270]  So this ties into device
[33:08.270 --> 33:10.410]  synchronization. Most IoT devices
[33:10.410 --> 33:12.230]  cannot talk to each other due to incompatible
[33:12.230 --> 33:14.090]  hardware and software. So
[33:14.090 --> 33:16.210]  LLOS is essentially
[33:16.430 --> 33:18.350]  a framework for developers to easily synchronize
[33:18.350 --> 33:20.350]  IoT devices, allocate control of them
[33:20.350 --> 33:22.490]  to a master SIG chain that's authenticated
[33:22.490 --> 33:24.130]  through Nexus. I gave you guys
[33:24.350 --> 33:26.490]  a quick example of how that all works.
[33:26.790 --> 33:28.170]  And it also
[33:28.170 --> 33:30.090]  there's one aspect of the
[33:30.090 --> 33:32.370]  API layer that allows you to create
[33:32.370 --> 33:34.390]  peer-to-peer communication. There's also
[33:34.390 --> 33:36.450]  powerline mesh connectivity, there's local
[33:36.450 --> 33:38.370]  mesh connectivity, and all these things
[33:38.370 --> 33:41.090]  that can integrate together and synchronize the devices.
[33:41.370 --> 33:42.430]  I sometimes, if I
[33:42.430 --> 33:44.370]  need to send a file from one computer to
[33:44.370 --> 33:46.290]  another computer, the operating system
[33:46.290 --> 33:48.450]  there's some with Apple, with AirDrop
[33:48.450 --> 33:50.110]  and stuff, but there's not
[33:50.110 --> 33:52.370]  very many, very easy
[33:52.370 --> 33:54.470]  to use device synchronization
[33:54.470 --> 33:56.490]  protocols. You have to download something else, you have to
[33:56.490 --> 33:58.430]  install it. I mean, even utilizing Linux
[33:58.430 --> 34:00.470]  it's very difficult for
[34:00.610 --> 34:02.450]  a non-developer to utilize it, even if you're
[34:02.450 --> 34:04.590]  using Mint or Ubuntu. They can kind of get around
[34:04.590 --> 34:06.510]  it, but there's a massive
[34:06.510 --> 34:08.570]  user issue. And part of that is also
[34:08.570 --> 34:10.410]  just the synchronization problem. So
[34:10.410 --> 34:12.550]  the Nexus operating
[34:12.550 --> 34:14.450]  system, or LLOS, kind of
[34:14.450 --> 34:15.750]  extends the user space
[34:16.330 --> 34:19.030]  out of the local hardware.
[34:19.170 --> 34:20.370]  Right? It
[34:20.370 --> 34:22.830]  creates a virtualized
[34:22.830 --> 34:24.370]  user space, which I believe
[34:24.370 --> 34:25.850]  is the next slide.
[34:26.130 --> 34:28.370]  It is not bound to the physical hardware, so
[34:28.370 --> 34:30.330]  it changes the idea of how we
[34:30.330 --> 34:32.370]  see a kernel, rather than actually being something
[34:32.370 --> 34:33.150]  that is
[34:34.450 --> 34:36.210]  managing just that local device.
[34:36.210 --> 34:38.050]  It kind of exists to manage
[34:38.050 --> 34:40.090]  the local device, but also the cache of
[34:40.090 --> 34:42.150]  the specific virtualized user space is logged
[34:42.150 --> 34:43.910]  in. So if I go
[34:43.910 --> 34:46.150]  to, let's say, my desktop, and I
[34:46.150 --> 34:47.890]  log in on LLOS
[34:47.890 --> 34:50.310]  to my username, password, and PIN,
[34:50.310 --> 34:52.270]  I will have my entire computer there.
[34:52.270 --> 34:54.050]  I will have my desktop, I will have my files,
[34:54.050 --> 34:55.890]  because it runs through a distributed
[34:55.890 --> 34:57.930]  file system, so you don't necessarily
[34:57.930 --> 35:00.070]  have to have everything locally
[35:00.070 --> 35:02.390]  bound. You just keep a local cache of that.
[35:02.790 --> 35:03.690]  And so the
[35:03.690 --> 35:05.830]  kernel then becomes responsible for populating
[35:05.830 --> 35:07.770]  this local cache of the user-level data
[35:07.770 --> 35:09.890]  from this distributed file system.
[35:09.890 --> 35:11.850]  So I could then go to my other computer
[35:11.850 --> 35:13.630]  and log into my SIG chain,
[35:13.630 --> 35:15.910]  one that has never, ever logged
[35:15.910 --> 35:17.650]  into that SIG chain before, and
[35:18.090 --> 35:19.690]  a very quick synchronization
[35:19.690 --> 35:21.630]  process will start happening in the backend
[35:21.630 --> 35:23.770]  that will be retrieving some of
[35:23.770 --> 35:25.770]  those files that are needed. And the
[35:25.770 --> 35:27.170]  other important quality is
[35:27.890 --> 35:29.810]  the LLOS out-of-box
[35:29.810 --> 35:31.850]  will work as part
[35:31.850 --> 35:33.690]  of a distributed computing framework. So
[35:34.690 --> 35:36.030]  if you have,
[35:36.030 --> 35:37.870]  let's say, 100 gigabytes or 200 gigabytes
[35:37.870 --> 35:40.090]  of free disk space, by default
[35:40.090 --> 35:42.190]  you'll be able to actually monetize that
[35:42.190 --> 35:44.470]  disk space through smart contracts, peer-to-peer
[35:44.470 --> 35:46.510]  smart contracts, by hosting data for other
[35:46.590 --> 35:47.650]  people. So what this creates
[35:47.650 --> 35:49.690]  is it creates a new type
[35:49.690 --> 35:51.930]  of environment. It's creating a
[35:51.930 --> 35:53.870]  level of indirection on top of the user
[35:53.870 --> 35:56.130]  space that exists now where the user space
[35:56.130 --> 35:58.010]  is in a bit more of a
[35:58.010 --> 35:59.810]  mathematical hyperspace
[35:59.810 --> 36:01.850]  rather than in your local computer.
[36:01.850 --> 36:04.070]  It's not locally bound.
[36:04.070 --> 36:06.270]  So you essentially get automatic backups,
[36:06.270 --> 36:08.070]  you get synchronization, and you
[36:08.070 --> 36:10.090]  get higher levels of security because
[36:10.090 --> 36:12.370]  all of the actions required to change
[36:12.370 --> 36:14.790]  your user space's state requires
[36:14.790 --> 36:16.030]  blockchain and cryptographic identifiers
[36:16.030 --> 36:18.090]  and cryptographic verification.
[36:18.230 --> 36:20.230]  So you get these high levels of security
[36:20.230 --> 36:22.170]  and there really becomes not
[36:22.170 --> 36:24.130]  much to take over
[36:24.130 --> 36:25.990]  on the local device. There's not, there's
[36:25.990 --> 36:28.150]  nothing there to commandeer because
[36:28.150 --> 36:30.410]  it exists kind of on a more elevated
[36:30.410 --> 36:31.830]  mathematical space
[36:31.830 --> 36:34.110]  so you reduce the attack surface from the
[36:34.110 --> 36:36.150]  actual physical hardware or
[36:36.150 --> 36:37.290]  the operating system
[36:37.950 --> 36:40.250]  into the actual virtualized user space
[36:40.250 --> 36:41.610]  so you'd have to attack
[36:41.610 --> 36:44.010]  the blockchain level information.
[36:44.010 --> 36:45.910]  You'd have to attack the blockchain subchain
[36:45.910 --> 36:47.710]  in order to try to manipulate
[36:47.710 --> 36:49.850]  and take over that specific computer.
[36:50.550 --> 36:52.310]  So, this local device
[36:52.310 --> 36:53.870]  will then become decoupled
[36:53.870 --> 36:56.150]  from the user space, making your computer exist
[36:56.150 --> 36:57.450]  in the distributed file system
[36:57.950 --> 36:59.690]  rather than just a local disk cache.
[36:59.690 --> 37:01.990]  And that also opens the doors, like I was saying
[37:01.990 --> 37:04.010]  earlier, for users to
[37:04.010 --> 37:06.330]  sell some of their actual physical disk space
[37:07.010 --> 37:07.530]  to
[37:07.530 --> 37:09.910]  essentially monetize their empty
[37:09.910 --> 37:11.930]  disk space on their computer and also
[37:11.930 --> 37:13.350]  pay other people to
[37:13.710 --> 37:15.910]  hold some of their collected backups.
[37:15.910 --> 37:18.050]  So, you get this new type
[37:18.050 --> 37:19.810]  of experience on a computer
[37:19.810 --> 37:22.030]  without the need for backing up any
[37:22.030 --> 37:23.850]  files because the system will
[37:23.850 --> 37:26.050]  exist in a more mathematical universe
[37:26.050 --> 37:28.290]  than a physically bounded universe.
[37:31.170 --> 37:32.070]  So,
[37:32.070 --> 37:34.090]  the conclusion is we authenticate
[37:34.090 --> 37:35.870]  every user action through this
[37:35.870 --> 37:37.870]  operating system. We protect
[37:37.870 --> 37:39.730]  against buffer overflow exports and file
[37:39.730 --> 37:41.910]  ejection techniques. And we do
[37:41.910 --> 37:43.690]  this through virtualizing the user space
[37:43.690 --> 37:45.890]  so the computer exists in a more
[37:45.890 --> 37:47.890]  mathematical hyperspace than on this local
[37:47.890 --> 37:49.830]  disk. And we're authenticating
[37:49.830 --> 37:51.810]  every device and develop a software-defined
[37:51.810 --> 37:53.990]  router so that every computer becomes a node
[37:53.990 --> 37:55.710]  in this mesh network. So,
[37:55.710 --> 37:57.910]  part of the design and the architecture is
[37:57.910 --> 37:59.910]  not only to improve the overall operating
[37:59.910 --> 38:01.830]  system security through Nexus
[38:01.830 --> 38:03.890]  OS, but it's also
[38:03.890 --> 38:05.950]  providing people the ability to
[38:05.950 --> 38:07.930]  connect and become a part of this new
[38:07.930 --> 38:09.270]  internet protocol.
[38:09.270 --> 38:11.350]  That, out of box,
[38:11.350 --> 38:13.350]  we'll just plug and play. So that
[38:13.350 --> 38:15.310]  the setup and drivers
[38:15.310 --> 38:17.370]  and all of that, the cumbersome setup
[38:17.370 --> 38:19.270]  that comes with setting up a new computer,
[38:19.270 --> 38:21.290]  we want to eliminate all of that while at the same
[38:21.290 --> 38:23.170]  time providing additional security
[38:23.170 --> 38:25.370]  properties to the computer using
[38:25.370 --> 38:27.430]  cryptographic authentication and
[38:27.430 --> 38:29.490]  like I said, identification and
[38:29.490 --> 38:31.230]  authentication on every level
[38:31.230 --> 38:33.250]  of the stack to become
[38:33.890 --> 38:35.230]  a new type of computing
[38:35.850 --> 38:37.310]  system that really
[38:37.310 --> 38:39.290]  changes the way that we see operating systems
[38:39.290 --> 38:41.290]  and changes the way that people design them
[38:41.290 --> 38:43.350]  and will also drastically change
[38:43.350 --> 38:45.810]  the way we see cyber security,
[38:45.810 --> 38:47.890]  especially on the operating system level.
[38:49.850 --> 38:52.010]  Questions and comments, everybody?
[39:36.730 --> 39:38.470]  Can you guys hear me?
[40:38.650 --> 40:40.390]  So, this operating system is
[40:40.390 --> 40:42.430]  also designed to be open-source
[40:42.430 --> 40:43.610]  and community-driven
[40:44.850 --> 40:46.430]  and we're building
[40:46.430 --> 40:48.770]  it somewhat as a group.
[40:48.770 --> 40:50.810]  We have quite a few people that are already
[40:50.810 --> 40:52.450]  getting involved on the early development
[40:53.070 --> 40:54.650]  such as some people from Cisco
[40:55.350 --> 40:56.790]  among others.
[40:57.790 --> 40:58.990]  So, if any of you
[40:58.990 --> 41:01.590]  would like to get involved on the development and architecture,
[41:01.590 --> 41:02.750]  like I said, we're designing
[41:02.750 --> 41:05.170]  this to be a new type of operating system
[41:05.670 --> 41:06.150]  that
[41:06.690 --> 41:08.750]  eventually can be utilized by
[41:08.750 --> 41:10.430]  most people.
[41:10.730 --> 41:12.850]  It's something that really extends
[41:12.850 --> 41:14.750]  the use of the
[41:14.750 --> 41:16.550]  computer in a totally different direction
[41:16.550 --> 41:18.430]  and it's also something that
[41:18.430 --> 41:20.790]  ties together with this new internet protocol
[41:20.790 --> 41:23.010]  and like I said, with software-defined
[41:23.010 --> 41:24.450]  routers, it allows us to
[41:24.450 --> 41:26.650]  essentially eliminate
[41:26.650 --> 41:28.890]  most of the hardware requirements that we have
[41:28.890 --> 41:29.950]  on the internet right now
[41:30.410 --> 41:32.210]  to create a more robust system.
[41:32.210 --> 41:34.350]  So, if there's any of you that
[41:34.350 --> 41:36.650]  find this inspiring or interested,
[41:36.650 --> 41:38.550]  definitely reach out
[41:38.550 --> 41:40.670]  to us. My email is
[41:40.670 --> 41:42.630]  Colin at Nexus.io
[41:42.630 --> 41:44.590]  and yeah,
[41:44.590 --> 41:46.690]  we'd love to have more people
[41:46.690 --> 41:48.690]  involved if there's some things that you'd
[41:48.690 --> 41:49.970]  like to add to it.
[41:50.330 --> 41:51.930]  It's a community-driven
[41:52.510 --> 41:54.710]  operating system that eventually
[41:54.710 --> 41:56.590]  we're going to make it
[41:56.590 --> 41:58.850]  with running zero-wine
[41:58.850 --> 42:00.530]  in a type of virtual machine
[42:00.530 --> 42:02.750]  so that you'll be able to execute Windows applications
[42:02.750 --> 42:04.650]  in a safe sandbox
[42:04.650 --> 42:06.570]  environment as a part
[42:06.570 --> 42:08.690]  of helping it integrate and get
[42:08.690 --> 42:10.410]  people kind of off of using Windows
[42:10.410 --> 42:12.630]  but making it an extremely
[42:12.630 --> 42:14.730]  easy-to-use user experience
[42:14.730 --> 42:16.670]  with all these different features and
[42:16.670 --> 42:18.610]  security properties. It really
[42:18.610 --> 42:20.810]  takes a lot of the erroneous
[42:20.810 --> 42:22.790]  crap out of using a computer.
[42:22.790 --> 42:24.930]  Right now, if you're not a very sophisticated
[42:24.930 --> 42:26.670]  individual, you'll have a lot of difficulty
[42:26.670 --> 42:29.050]  maintaining the security.
[42:29.050 --> 42:30.610]  So, this is something that should
[42:30.610 --> 42:32.750]  out-of-box produce that security
[42:32.750 --> 42:34.790]  for someone without all the setup
[42:34.790 --> 42:36.810]  costs. So, if this is interesting
[42:36.810 --> 42:38.830]  to any of you, definitely reach out.
[42:38.830 --> 42:41.290]  Again, my name is Colin Kentrell.
[42:41.290 --> 42:43.250]  My email is colin
[42:43.250 --> 42:44.750]  at nexus.io
[42:45.290 --> 42:46.970]  Like I said, the architectural
[42:46.970 --> 42:48.370]  development of this is
[42:49.120 --> 42:50.110]  very, very
[42:51.250 --> 42:52.890]  close to complete.
[42:52.890 --> 42:54.950]  And the initial implementation over the next
[42:54.950 --> 42:56.990]  year or two is being designed
[42:56.990 --> 42:58.910]  to run on essentially basic
[42:58.910 --> 43:01.330]  IoT devices and the Cube satellites.
[43:01.350 --> 43:03.030]  And then a couple years down the road
[43:03.030 --> 43:04.910]  from there, we will be creating
[43:04.910 --> 43:06.410]  the more consumer version of it
[43:06.410 --> 43:08.910]  which is going to create that ease of
[43:08.910 --> 43:10.890]  use and everything like that. So, if you
[43:10.890 --> 43:12.770]  guys want to get involved on the
[43:12.770 --> 43:14.770]  early formations of this new
[43:14.770 --> 43:16.430]  internet protocol and operating system
[43:16.430 --> 43:18.590]  and blockchain technology, we would definitely
[43:18.590 --> 43:20.930]  love to get you involved.
